broker: add storage read/write and live-signal actions to the contract - #6922

What

Extends the broker action contract (buzz-sdk::broker) with six actions in two groups. Four were named as deferred by #6742 (memory read/write, presence.set, typing.set); the other two, observer.emit and liveness.ping, are net-new — the trajectory and keepalive planes the contract never enumerated.

Storage — memory read/write (deferred by #6742):

Live signals — the ephemeral signals a running agent emits so an owner and channel can see it work:

All six mirror the existing nine in shape, validation, strict-wire rules, and test coverage. The four signal actions are best-effort — a host that doesn't offer one refuses it and the agent carries on.

Why

A keyless agent routes everything through the broker host and holds no relay connection, so anything a local agent emits directly to the relay needs an action or it silently can't happen. #6742 shipped the nine core actions and named four deferrals; this PR:

• graduates the deferred storage + presence/typing — storage.address could address an encrypted-memory record but not read or write one (a keyless runtime was amnesiac across wakes), and presence/typing are how an owner and channel see an agent is alive and composing (the presence dot, the typing bubble);
• adds observer.emit and liveness.ping, which broker: define the agent-to-broker action contract #6742 didn't enumerate — the observer/trajectory stream in Buzz Desktop and a turn keepalive. These fell out of the keyless-observability discussion: without them a keyless agent runs invisibly, with no way to surface its tool calls or prove a long turn is still alive.

Decisions baked in (all up for discussion)

• Host does all the crypto and Nostr work — owner pubkey, NIP-44 encryption, signatures, kinds, and the observer batching/pacing are host-derived; the agent supplies only semantic content. Same separation as the rest of the contract.
• observer.emit is a batch — trajectory is high-volume, so frames are sent per call and the host re-batches/paces. Each frame is { kind, payload } where payload is opaque (a serialized frame body the host encrypts verbatim, never parses); kind stays top-level so a host can apply per-kind policy without decrypting. The outcome is a batch receipt { accepted }, since re-batched frames have no stable per-frame id.
• Ephemeral, not persisted — these frames exist only for a live watcher; persistence, if ever wanted, is a separate system.
• liveness.ping is its own action despite overlapping observer.emit on the wire (a keepalive could be one more frame). Keeping it separate lets a host attach meaning — resetting a stall watchdog — rather than only forwarding it. Flagged in the module docs; happy to collapse it if preferred.
• typing.set has no stop counterpart — the indicator is ephemeral and lapses on its own; a client signals by re-sending and stops by falling silent. Thread-scoped typing is a purely-additive later refinement.
• presence.set reuses buzz_core::presence::PresenceStatus (online/away/offline) rather than minting a parallel enum.
• (storage half) slug-addressed, missing record → absent value, no patch/rm — a client composes those from read-modify-write, as profile.set already does.

Open questions for review

1. liveness.ping vs observer.emit — worth a first-class action, or fold it in?
2. Observer bounds — MAX_OBSERVER_FRAMES = 256 per call, MAX_OBSERVER_FRAME_BYTES = 64 KiB per frame. Reasonable for trajectory volume?
3. storage.address fate — with slug-addressed get/put, does address still earn its place (existence checks / coordinates without a payload)? Left in place either way.

Scope / sequencing

Contract crate only — self-contained and mergeable on its own (nothing on main matches these enums exhaustively outside buzz-sdk). When the keyless client branch rebases onto this, buzz-cli's exhaustive matches gain the six variants — the forcing function to implement them over the host seam — which is where the client's memory refusals and disabled observer path get removed.

Two commits, reviewable independently: storage.get/storage.put, then the four signals.

Verification

• cargo test -p buzz-sdk — 302 passed. The self-enforcing coverage, round-trip, null-injection, canonicalization, and exact-schema tests all extend to the new actions automatically.
• cargo clippy -p buzz-sdk --all-targets -- -D warnings — clean.
• cargo fmt -p buzz-sdk -- --check — clean.
• cargo check --workspace — clean.

🤖 Generated with Claude Code